为什么移动开发者不要轻易立项待办TODO类工具
⬆️欢迎戳蓝字关注⬆️
最近有一个工具领域的哥们询问我待办清单这类项目怎么样，还举了个做的很成功的例子。
“感觉很赚钱”。
上班族白领赚到了“第一桶金”后容易想到的实体店创业三板斧：咖啡、猫宠、鲜花店。
程序员做个人项目，容易想到的游戏三板斧：flappy bird，2048，俄罗斯方块，而工具三板斧则是：待办、日记、记账本。
为什么行业很容易出现萌新立项三板斧，归根结底就是平时被螺丝钉式的工作局限住（客观上），又缺乏足够的行业大范围调研，懒得做或者不屑于去做，更相信自己的直觉（主观上），因此选择范围直接就被局限住了，所以想出来的项目，来来去去这几件，你能想到我也能想到。
工具领域的待办清单（Todo List），就好比实体店中的咖啡厅，都是给一些人无比美好憧憬，恨不得赶紧投身进去的项目，而扎进去大部分人挖到的不是金矿，而是泥巴。
如果是入局工具领域的开发者，也想做一把待办清单过过瘾，那么先压抑自己的热情，给这个项目做个基础评估（参考《产品选型的评估思路》），如果评估后觉得自己还想做，那才是真的想做。
依据评估的思路，可以把待办清单分成以下几个开发阶段。
最小可用版本：开发周期偏低，版本价值也低。
完善可用版本：开发周期较长，版本价值中等偏低。
最佳可用版本：开发周期漫长，版本价值高但取决于多方因素。
Todo 的最小可用版本就是一个基础的待办事项的增删查改工具。这是能定义的不可再削减的最小版本了。但是这个版本开发完毕后，这个产品并没有什么价值，因为系统自带的已经够好了。
完善可用版本，那么要做的就真的多了。例如待办事项必须有子项目，才能满足大任务的分切需求，必须得有标签或者分类，对于项目必须有备注、附件甚至插图功能，得满足搜索需求，得加入用户可配置的时间选项，这样可以配置任务的结束时间等。
可以看出，做出一个完善可用版本，项目周期拉长了相当多。那么拉长出那么多开发周期后，开发者能得到回报吗（也就是回收成本）。答案是不能，因为这些所谓的“完善”功能，只是目前待办事项工具领域的基础配置而已。
这就是待办清单的另一个重要问题，同类产品太卷了，这类需求太容易被想到了，做的人太多了，因此用户预期也是无限被拉高的。
最佳可用版本，可以做的事情就太多了。但是其实在诸多待办领域的山大王眼里，也不过是区区基本款。如：
多账号在线同步。
任务执行的管理，如专注模式，番茄时钟等。
日历、日历同步和视觉化展现。
外观选择，如换肤、主题等。
提醒声音管理等。
多平台支持（包括网页版）
如果觉得待办清单真的需要有这么多功能而不显得臃肿吗？那么可以去深入体验下滴答清单这类产品，你就会发现功能多和看起来不臃肿，完全是可以共存的。
重要的是，做到了以上这些，开发者还不可以急着盈利，因为待办事项这一类效率工具，本身就不允许你急着盈利。就别说广告具体应该怎么设计了，哪怕你弹一次广告，你的产品设定形象可能就岌岌可危。
更别说终极版本的“数据同步”和“多平台支持”这两样的成本了，这些可不是所谓加分项，对于 TODO 爱好者甚至已经是基础配置一样的存在了。
而只有把以上这些全部做透做好（开发者可以评估下究竟需要多少个人工时），产品才可以谨慎的考虑更进阶的付费环节。
参考滴答清单的付费设定如下：
很显然，这款产品的核心收益来自于筛选优质付费用户，基础用户用基础功能非常够用了，而付费用户属于进阶深度用户，是愿意为进阶功能付费的。
这所有功能里，最核心的功能应该是“数据同步”，数据同步包括跨平台，跨账号同步，还包括多账号共享同步（家庭、团队需求）， 只有这一部分做的足够稳定和扎实，消费者有了安全感，有了粘性，才愿意为最后的付费部分买单。BTW，数据多账户和跨平台同步这部分还必须得是免费的，所以开发者必须承担服务端从研发到日常维护的所有开销。
因此，总结下通用 Todo 这个品类的产品门槛如下：
本身就是系统级功能，用户对产品预期高。
同类产品进场早，成长得很强大，超越难度大，差异化难度也大。
商用化版本的开发成本，远比开发者预期要高。
总之，Todo 工具现在是彻底的慢工出细活的品类，从营收角度来讲，它的立项价值真的很低。除非开发者本身具备足够的热情（我很怀疑这一点）和实力以及执行力，决心要做一款不同于市面产品的工具，才有机会做好。而即使是做好，从做好到实现收益，也是一个漫长的过程，在这个过程中如果着急想收钱，很可能导致口碑崩塌和用户流失。
TODO 工具的问题，只是目前 App 生态中很多工具内卷的一部分体现。对于一个特别卷的品类，客观上开发者必须有足够的资源支撑自己去竞争，主观上开发者还不能单纯把它当用完即走的捞钱工具，而必须把它当一项独立的事业，用老土的话来说，开发者得为爱发电，才能真正把这种品类做好。
完。
附：